秒开率破90%-交易后台渲染性能优化 ｜ 得物技术

目录

一、前言

二、系统简介

三、性能现状

    1. 性能看板分析

    2. 渲染流程分析

四、方案拆解

五、具体动作

    1. 首屏资源优化

    2. 渲染优先级优化

六、效果回收

    1. 主要性能指标

七、总结展望

一

前言

一直以来，体验都是得物技术部的关键词之一，对于前端开发而言，提高用户体验更是一项至关重要的工作。

本文从本次交易后台性能优化实践出发，同时介绍应用整体架构和设计，希望可以给参与网站性能建设的同学提供一定的学习和参考价值。

二

系统简介

交易后台是现有交易流程主要系统，包含商品、出价、商家、订单等二级业务域，其承载了交易的核心任务，在交易平台的整体架构中占据着非常重要的地位。

业务背景：整体日均 PV 数达到 10w+，其中 SPU 场景占比超过一半，由于页面功能结构复杂的原因，运营的使用体验和交易效率有一定程度上的影响。

技术背景：应用基于 qiankun 微前端架构，首屏加载资源过多，包括主子应用 JS 和样式文件，图片和其他静态资源，数十个子应用路由信息和数百个菜单项，以及接入的一些三方 SDK 等。

三

性能现状

先看优化前的首屏效果（没有开慢倍速）：

可以从动图看出页面加载速度、白屏时间都不太理想，显然和我们的目标首屏秒开还有一段距离，为了实现首屏秒开的目标，可以先从以下几个方面进行分析。

性能看板分析

Chrome Performance 火焰图在页面性能问题分析中是一项非常重要的工具。

相关阅读：https://juejin.cn/post/6844904074551230471

在打开看板后，先关注下这几个红色区域长任务，我们知道主线程一次只能处理一个任务，所以这会导致浏览器在主线程上阻塞一段时间，也是造成页面卡顿的主要原因。看下底部调用树的情况：

Task1：发生在 DCL 之前，因为浏览器解析 HTML 文件时，会在遇到<script>标签时立即执行脚本文件，所以 __webpack_require__ 和 Compile Code 很可能是因为入口文件过大导致。

Task2：发生在 FCP 之后，主要是源码中组件渲染相关的核心函数，componentUpdateFn 用于比较新旧 VNode 的差异，并调用 patch 函数对真实 DOM 进行更新，所以初步判断是渲染复杂组件导致。

另外可以观察以下关键性能指标，了解一下页面加载的各个阶段的耗时情况

• First Contentful Paint（FCP）：首次内容绘制时间，此时页面仅展示出一些水印组件，和白屏几乎没区别，一般应该在页面加载后的 1-2s 内完成，此时用户可以感受到页面正在加载。（当前耗时2s+）
• Largest Contentful Paint（LCP）：最大内容绘制时间，此时主应用框架渲染基本完成，子应用还未开始加载。通常应该在页面加载后的 2.5s 内完成，否则用户可能会感到页面加载缓慢。（当前耗时4s+）

根据这些具体的性能指标，之后才能更好的度量优化效果。

渲染流程分析

为了快速定位问题，我们按步骤拆分一下页面整体加载的渲染流程，这有助于我们做出针对性的优化。

我们重点关注几个标记的部分，接下来就可以根据实际情况逐一击破了。

四

方案拆解

根据对应用渲染流程的分析，我们可以将整体优化方案作进一步的拆解，并设置对应动作的开发优先级。

并通过二八法则，我们将主要精力重点投入到高优方案中，确保整体性能的提升。

五

具体动作

首屏资源优化

首屏资源加载会直接影响页面的渲染速度和体验，我们先查看下首屏资源的加载情况，由于各类资源请求过多，这里仅过滤来源于主应用的网络请求。

可以直接从中发现几个可优化的点：

• 入口 JS 资源文件 Size 优化
• 严重影响了页面整体加载性能，可以通过构建体积优化，主要思路就是代码分割拆包，静态资源上传 CDN，脚本代码压缩等方式处理
• 接口缓存、调用时序治理
• 针对用户信息、菜单信息等不常变动的接口可以采用相关缓存策略，减少首屏等待的时间
• 部分优先级不高的接口可以延迟调用，异步加载

// 我们采用 Cache aside 旁路缓存策略
async function cacheRequest(params: any) {
  const startTime = Date.now()
  const key = params.key
  const cache: any = JSON.parse(localStorage.getItem(key) || '{}')
  // 当天有缓存
  const canCache = cache.cacheTime && moment(cache.cacheTime).isSame(moment(startTime), 'day')

  window.sendTrack?.({
    event: 'main_request_cache',
    tags: {
      eventTitle: '主应用数据缓存',
      eventType: canCache ? 1 : 0,
    },
  })

  const requestCache = async () => {
    const data = await request(params)
    localStorage.setItem(key, JSON.stringify({
      data,
      cacheTime: Date.now()
    }))
    return data
  }
  // 优先从缓存中读取数据 后续再更新缓存 保证数据的一致性
  if (canCache) {
    setTimeout(requestCache, DELAY_CACHE_TIME * 1000)
    return cache.data
  } else {
    const data = await requestCache()
    return data
  }
}

• 三方 SDK 集中治理
• 尽量放在 script 标签中异步加载脚本，可以加快解析时间且保证主入口文件的加载不会被阻塞
• 另外注意防止子应用重复加载，还有部分 SDK 需要及时下线

其实原则只有一个：减少首屏需要加载的资源数量和大小，并尽快加载必要的资源。

渲染优先级优化

最后为了减少 LCP 的等待时间，我们将页面左侧菜单栏做一个懒加载处理，初始化仅展示一级目录菜单，既考虑了首屏视觉效果，也间接将子应用加载的时间点提前。

相关阅读：当不希望因为不重要的任务导致用户感觉到卡顿的话，就应该考虑使用requestIdleCallback：https://juejin.cn/post/6844903592831238157

// 采用 requestIdleCallback 方式利用 CPU 空闲时间渐进地加载内容
try {
    requestIdleCallback((deadline) => {
        // 当前帧有剩余时间 可以执行任务
        while (deadline.timeRemaining() > 0 && || deadline.didTimeout) {
            // 加载剩余部分菜单项
        }
    })
  } catch (e) {
    // 低版本浏览器兜底处理
    setTimeout(() => {
      // 加载剩余部分菜单项
    }, DELAY_LOAD_TIME)
  }
}

最后再看下优化后的首屏效果（没有开快倍速）：

六

效果回收

主要性能指标

优化后各项指标数据均有一定提升，其中

秒开率（首次打开页面<1秒占比，以 FMP 为准）：🔝15%+

页面首次进入FMP90分位均值（秒）：🔝35%+

页面TTI%(可交互时长<1.5s占比) ：🔝30%+

TTI 90分位均值（秒）：🔝50%+

上述数据均来源于效率工程应用系统前端大盘看板。

优化前-7月

优化后-9月

其他相关数据统计（本机测试）：页面传输资源大小减少约 1M、页面资源加载时间下降超过 0.5s、FCP、LCP 也分别优化到 1s、2s 以内 ，整体结果超出预期。

七

总结展望

随着业务复杂度提升和用户规模的增加，系统的性能和效率必然会面临更多的挑战，本轮性能优化工作基本告一段落，虽然取得了一些成绩，但还有很多事项需要后续不断的完善，比如：

1. 框架层面优化。深入探究微前端框架层的性能瓶颈，降低应用间消息传递通信和模块重复资源加载损耗
2. 使用 Service Worker。执行一些计算密集型或网络请求相关的任务，实现静态资源缓存优化
3. 资源加载优化。利用发布平台事件同步能力实现应用配置文件按需加载，避免网络带宽造成过大的压力

希望能通过各项措施逐步形成后台应用性能优化最佳实践，从而避免各种性能卡点问题，进一步保证运营体验。

往期回顾

文 / Johnny

关注得物技术，每周一、三、五更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

“

扫码添加小助手微信

如有任何疑问，或想要了解更多技术资讯，请添加小助手微信：